package com.coderman.infosys.auth.domain.support.bo;

/**
 * Description:
 * 在domain这一层中support这个可以理解为一个支持包或者支撑领域，更确切的可以算是support.domain.bo
 * 或者support.domain.xx
 * 由于support本身可以放其他的工具包或者工具类，这里我们仅讨论下游依赖领域对象(包括实体和值对象)的处理方式
 * 所以现在对于支撑领域对象在核心领域对象中有几种处理方式
 * 1.跟自己核心领域一样处理，比如把UserBO放在domain.bo.user包里
 * 2.把UserBO与核心领域的BO类分开，但是同时仍然放在domain层，只是包是domain.support.bo
 * 3.把UserBO或者像DepartmentBO这样的支撑领域的类去掉，核心领域的对象只依赖其ID或者code
 *
 * 由于是支撑领域肯定跟下游的接口或者消息有交互，那么对于对象转换其实也有一些区别
 * 跟着上面的方案走的话就需要让BO转换为下游接口的DTO
 * 或者在auth-infrast模块的auth.infrast.acl中定义请求和响应DTO然后来用DTO 与下游DTO进行转换，这么做可能会显得很奇怪，所以最好的方式
 * 仍然是区别核心领域对象与支撑领域对象，那么auth.infrast.acl里面的请求响应对象DTO可以去掉了，对于supportBO到下游的接口请求RequestDTO的转换仍然可以在
 * auth.infrast.acl中进行转换。
 *
 *  有一种场景可以讨论一下就是在domain中有实践是对业务对象的命名变成 CreatexxBO,UpdatexxBO,这种命名方式本身也代表类一种业务操作对象，但是可能会导致领域对象处于一种割裂的状态
 *  当我们需要返回的时候我们可能需要返回xxBO这种相同业务对象下的实体模型，此时对于领域层来说就不再变得干脆，如果业务迭代频繁增加字段，或者业务场景变得相对复杂那么这种情况就显得有点
 *  麻烦了，有时候可能会因为在领域模型中参杂了这种Request,Response的业务含义会让业务实体类或者业务模型在业务迭代中变得相对迟钝，由于映射偏移的影响，底层的数据模型可能很长时间都不会有什么变动，在技术决策的时候可能会
 *  有更多的顾及而寄希望于尽量保持当前的模型不变去迎合新的业务需求。
 *
 *  这么做当然也有一点好处就是稳定，不会有太大的模型重构或者调整而影响整个业务核心领域。
 *
 *  所以对于Request,Response怎么用，在哪里用的合适等等，还需要继续琢磨，当然这里也很晚了，不继续自我解释了。
 *
 *
 * date: 2022/1/8
 *
 * @author shenshuai
 * @version 1.0.0
 * @since JDK 1.8
 */
public class DepartmentBO {
}
